Method and apparatus for dynamically brokering object messages among object models

ABSTRACT

The present invention dynamically brokers object messages between object models. A mediating component provides a bridge between object models such that messages can be transmitted in either direction between object models. The mediating component can be resident on a client machine, a server machine, or both. The mediating component can be used as a bridge between two instances of the same object model running on different machines. Thus, network communication is made possible for objects of an object model that otherwise lacks a networking capability. A client object&#39;s message is forwarded to a server object. The mediating component performs any necessary translation of arguments or format of the message. In addition, the mediating component translates a server object&#39;s response.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to dynamic brokering of messages between objectsimplemented using like or different object models.

2. Background

Object-oriented programming is a method of creating Computer programs bycombining certain fundamental building blocks, and creatingrelationships among and between the building blocks. The building blocksin object-oriented programming systems are called “objects.” An objectis a programming unit that groups together a data structure (instancevariables) and the operations (methods) that can use or affect thatdata. Thus, an object consists of data and one or more operations orprocedures that can be performed on that data. The joining of data andoperations into a unitary building block is called “encapsulation.” Inobject-oriented programming, operations that can be performed on thedata are referred to as “methods.”

An object-oriented software application uses objects to define its dataand the methods that operate on the data. An object communicates withanother object via messages. For example, when one object needs tomanipulate data that resides in another object or needs to executecomputation methods in another object, it sends a message. Therequesting object identifies the desired manipulation operation byspecifying a method. The requesting object can further send argumentsthat can be used by the second object in performing the named method.The servicing object performs the method requested in the message. Thedata provided by the requesting object can be used to perform therequesting operation. In client/server terminology, the requestingobject is called the client object and the servicing object is calledthe server object.

When the client and server objects are running in the same computer andoperating system or in the same process or memory address space, theprogram or system can use its own mechanisms for messaging and objectidentification without regard for any other systems. The physicallocation of the objects is determined, known, and maintained by thesingle system. In a distributed environment, however, objects can resideon different systems and across networks, for example. Thus, in adistributed environment, a client object may need the services of aserver object that resides on a remote system. Not all object modelsprovide for such remote requests. Also, the remote system may use anobject messaging mechanism that is incompatible with the client object'smessaging mechanism. In that case, the client object and server objectcannot communicate or “interoperate”.”

An object model provides a mechanism for communication, or messaging,between objects within the model. The mechanism includes a protocol thatdefines the method of communication. Examples of object models includethe NeXT object model, Microsoft's Object Linking and Embedding/CommonObject Model (OLE/COM), SunSoft's Distributed Object Environment (DOE),and Smalltalk. To facilitate communication, an object model can use anobject bus, or an Object Request Broker (ORB). An ORB allows objects tomake requests of, and receive responses from, other objects. Examples ofORBs include CORBA (defined by Object Management Group), SOM from IBM,ORB Plus from HP, ObjectBroker from Digital Equipment Corporation, andOrbix from Iona.

An ORB uses an Interface Definition Language (TDL) to define staticinterfaces between objects. For example, an interface defines themethods and properties, or arguments, for each object. An interface filewritten in IDL is compiled to generate client and serverlanguage-specific stubs such as C, C++, Objective-C, etc. These stubsmust be compiled into both the client and the server before anycommunication can take place.

These language-specific stubs define how clients invoke correspondingservices on the servers. From a client's perspective, the stub acts likea local call. The stub is a local proxy for the remote server object.The stub includes code to encode and decode an operation and itsparameters into a compacted message format that can be sent to theserver. This is referred to as marshaling. Several ORBs, including theCORBA ORB, are described in detail in R. Orfali et al., “The EssentialDistributed Objects Survival Guide” (New York: John Wiley & Sons, 1996).

In addition to the language-specific stubs, CORBA provides someapplication program interfaces (APIs) on the client-side to facilitateobject communication. A Dynamic Invocation Interface provides APIs thatcan be used to look up the metadata that defines the server interface,generate message parameters, issue a remote call, and receive resultsfrom the call. An Interface Repository is a run-time database thatcontains machine-readable versions of the IDL-defined interfaces. TheAPIs associated with the Interface Repository provide mechanisms forretrieving, storing and updating the metadata information contained inthe Interface Repository. The ORB Interface includes APIs to convert anobject reference (i.e., a unique name or identifier associated with anobject) to a string.

Like the client side, the server side includes IDL stubs, or serverstubs. A server stub is also referred to as a skeleton. Like a clientstub, a server stub is defined using IDL and created using an IDLcompiler. A server stub provides a static interface to a serviceprovided, or exported, by a server. It calls the method on the serveridentified by the client. On the server side, CORBA providesfunctionality to aid in servicing a request.

A Dynamic Skeleton Interface provides a run-time binding mechanism tohandle incoming method calls directed to a server that does not have aserver stub. An object adapter provides the run-time environment forinstantiating a server object, assigning an object reference to a serverobject, and passing it a request. An Implementation Repository is arun-time repository that identifies the classes a server supports, theobjects that are instantiated, and the instantiated objects' objectreferences. Administrative data such as trace information can also bestored in the Implementation Repository. The server side includes an ORBInterface that is the same as that used on the client side

Existing object models such as the ones identified above do not providea means for dynamic communication across object models. Thus, an OLEobject cannot automatically and dynamically communicate with an objectin the DOE object model. When a programmer is preparing an applicationprogram that must communicate across object models, the programmer mustidentify the destination objects to the ORB by declaring and definingthem in an IDL method file. The IDL method file is then compiled inconjunction with run-time libraries of each object model, producingseparate executable files for the client and server. This process mustbe repeated when a method or property of an object changes or when theapplication program is modified to reference new objects in a foreign orincompatible object model, for example. Thus, the ORBs only provide astatic means for communicating across object models. The ORB is notcapable of dynamically passing a message from one object model to anincompatible object model without prior knowledge of the method.

In OLE Automation, a subset of the OLE/COM object model from MicrosoftCorporation (MS), a set of object definitions (or ODL) is compiled tocreate a type library or repository of object descriptions (e.g.,objects and their methods and properties). Before invoking a method inan object, an OLE/Automation client object queries the library, or thelibrary itself, to determine whether a server object can process thedesired method. To do this, the object invokes the GetIDsOfNames methodon the server object to determine whether the desired method is a validmethod of the server object.

The GetIDsOfNames method converts text names of properties and methodsinto a corresponding set of dispatch identifiers (dispIDs). A dispIDuniquely identifies a method or argument. It is assigned to a method orargument in an object description file that is compiled before run-time.Thus, if a method or property is added, a new dispID must be generatedand compiled into the server.

If the response from the GetIDsOfNames method returns a dispID for thedesired method, the client object invokes the method on the serverobject using the dispID to identify the method. If it is not a validmethod, the client object must handle the error. If the method exists,but an error is raised during processing, the client object must handlea different error. This is awkward because it requires the applicationprogrammer to write code to handle at least two types of error messages.

Further, this process requires the client object to send two messages.When the client and server objects do not reside on the same machine,the messages must be sent across a network between the client and serverobjects to invoke a single method. This increases the network's messageload, which is undesirable.

SUMMARY OF THE INVENTION

The present invention dynamically brokers object messages betweenobjects implemented using object models. An mediating component providesa bridge between objects in these object models such that messages canbe transmitted in either direction between object models. The mediatingcomponent can be resident on a client machine, a server machine, orboth, depending on the type of communication being done. The mediatingcomponent can be used as a bridge between two instances of the sameobject model running on different machines. Thus, a networked version iscreated for an object model that otherwise lacks a networkingcapability.

The mediating component intercepts messages sent by a client object tothe server object. That is, messages sent by a client object are sent tothe server object via the mediating component. However, the clientbelieves that the messages are being sent directly to the server object.The mediating component creates a mapping between a client object and aserver object. Mapping information is determined by the mediatingcomponent when a client object requests a connection to the serverobject.

When a client requests a connection to a server object, the mediatingcomponent determines whether the server object is available on theserver machine. If the server object is available, the mediatingcomponent returns a proxy (e.g., returns pointer to or identifier forthe proxy object) for the server object to the client object. If theproxy object does not already exist, the mediating component creates theproxy object.

If the stub object associated with the server object does not exist, itis created by the mediating component. The mediating component creates amapping between the proxy object returned to the client object, theserver object's stub object and the server object. The mappinginformation can be stored in one or more tables, for example. A tablelook up mechanism can be used to retrieve the mapping information.

The mapping information can be used to satisfy a future connectionrequest. When a connection request is made for a server object, themediating component queries the mapping information to determine whethera mapping already exists for the requested server object. If a mappingdoes exist, the identity of the proxy object is returned to the clientobject.

The client object uses the connection to send a message to the serverobject. A client object's message is forwarded to a server object viathe proxy and stub objects. The mediating component performs anynecessary message translation. In addition, the mediating componenttranslates a server object's response.

The client object's message is generated using the message protocol ofthe client object's object model. The client object's message istranslated into the message protocol of the server object's objectmodel. For example, the proxy object determines the expected methodidentification and the number and type of arguments for the serverobject.

The proxy object builds a method invocation for the server object usingthe client object's message and the information expected by the serverobject. For example, the proxy object translates a method identificationin the client object's message to one expected by the server object. Inaddition, the proxy object can translate the arguments such that thetypes of arguments provided in the client object's message are the sameas the expected types. For example, a string argument can be translatedinto an object argument.

A translated message is forwarded to the server object on the servermachine via the proxy and stub objects mapped to the server object bythe mediating component. The proxy object forwards the translatedmessage to the stub object. The stub object forwards the translatedmessage to the server object. The server object processes the message. Aresponse is forwarded to the proxy object via the stub object. The proxyobject translates the response message using the client object's messageprotocol. In addition, the proxy object can translate the response suchthat the response type is that expected by the client object. Themessage is forwarded to the client object.

The mediating component delays the creation of a server machine stackuntil it is determined that a method is callable on the server machine.A message is forwarded to the server object via a plurality ofintervening objects such as the proxy and stub objects on the servermachine. The invention waits until the message is received by the lastintervening object (e.g., the server object's stub object) before themessage is unraveled. Otherwise, each intervening object would retrievethe method and arguments from the message, push the arguments on astack, attempt to invoke the method, fault, rebuild the message, andforward the message to another object. The invention optimizes themessage transmission by eliminating the need to unravel the message ateach intervening point.

The mediating component can be resident on the client, server, or both.The mediating component can act as a bridge between compatible orincompatible object models.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 provides an example of a general purpose computer to be used inaccordance with embodiments of the present invention.

FIG. 2 provides a block diagram giving an overview of embodiments of thepresent invention.

FIGS. 3A-3C provide configuration examples according to embodiments ofthe present invention.

FIGS. 4A-4C provide a process flow according to an embodiment of thepresent invention for brokering object messages using a bridge on theserver machine.

FIGS. 5A-5C provide a process flow according to an embodiment of thepresent invention for brokering object messages using a bridge on theclient machine.

FIGS. 6A-6C provide a process flow according to an embodiment of thepresent invention for brokering object messages using a bridge on boththe client and server machines.

FIG. 7A provides an example of a process flow for translating argumenttypes from the NEXTSTEP/OPENSTEP environment to the Windows environmentaccording to an embodiment of the invention.

FIG. 7B provides an example of a process flow for translating argumenttypes from the Windows environment to the NEXTSTEP/OPENSTEP environmentaccording to an embodiment of the invention.

FIGS. 8A-8B provide an example of a process flow for establishing aconnection and generating a mapping between client and server objectsaccording to an embodiment of the invention.

FIG. 9 provides an example of a delayed stack creation process flowaccording to an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

A method and apparatus for dynamically brokering object messages amongobject models is described. In the following description, numerousspecific details are set forth to provide a more thorough description ofthe present invention. It will be apparent, however, to one skilled inthe art, that the present invention may be practiced without thesespecific details. In other instances, well-known features have not beendescribed in detail so as not to obscure the invention.

The present invention can be implemented on a general purpose computersuch as illustrated in FIG. 1. A keyboard 110 and mouse 111 are coupledto a bi-directional system bus 118. The keyboard and mouse are forintroducing user input to the computer system and communicating thatuser input to CPU 113. The computer system of FIG. 1 also includes avideo memory 114, main memory 115 and mass storage 112, all coupled tobi-directional system bus 118 along with keyboard 110, mouse 111 and CPU113. The mass storage 112 may include both fixed and removable media,such as magnetic, optical or magnetic optical storage systems or anyother available mass storage technology. Bus 118 may contain, forexample, 32 address lines for addressing video memory 114 or main memory115. The system bus 118 also includes, for example, a 32-bit DATA busfor transferring DATA between and among the components, such as CPU 113,main memory 115, video memory 114 and mass storage 112. Alternatively,multiplex DATA/address lines may be used in place of separate DATA andaddress lines.

In the preferred embodiment of this invention, the CPU 113 is a 32-bitmicroprocessor manufactured by Motorola, such as the 680X0 or PowerPCprocessor or a microprocessor manufactured by Intel, such as the 80X86or Pentium processor. However, any other suitable microprocessor ormicrocomputer may be utilized. Main memory 115 is comprised of dynamicrandom access memory (DRAM). About 32 megabytes of DRAM preferred. Videomemory 114 is a dual-ported video random access memory. One port of thevideo memory 114 is coupled to video amplifier 116. The video amplifier116 is used to drive the cathode ray tube (CRT) raster monitor 117.Video amplifier 116 is well known in the art and may be implemented byany suitable means. This circuitry converts pixel DATA stored in videomemory 114 to a raster signal suitable for use by monitor 117. Monitor117 is a type of monitor suitable for displaying graphic images.

The computer system described above is for purposes of example only. Thepresent invention may be implemented in any type of computer system orprogramming or processing environment. When a general purpose computersystem such as the one described executes the processes and processflows described herein, it is configured to dynamically broker objectmessages among object models.

FIG. 2 provides a block diagram overview of an embodiment of the presentinvention. Mediating component 204 provides a bridge between objectsimplemented using object models. For example, mediating component 204provides a bridge between system A 202 (which uses object model A) andsystem B 206 (which uses object model B).

Systems A and B (202 and 206, respectively) provide a platform in whichobject models A and B operate. Systems A and B each may be a machine,process, client, or server. System A 202 can include operating systemsoftware such as the NEXTSTEP, or OPENSTEP framework that executes inthe Mach operating system. System B is the Windows environment runningin the DOS operating system, for example.

Object model A can be a different object model than object model B. Forexample, object model A may be NeXT Software, Inc.'s Distributed Object(DO) model and object model B may be Microsoft, Inc.'s Object Linkingand Embedding/Component Object Model (OLE/COM).

Alternatively, object model A can be the same object model as objectmodel B. In this case, mediating component 204 can act as a bridge in anetwork environment such that an object in an object model can bedistributed across different machines. That is, the bridging capabilityof the present invention can be used to create a network version of anobject model. The present invention can be used to allow a server objectresiding in OLE/COM on a first machine to service a message generated bya client object that resides in OLE/COM on a second machine.

Mediating component 204 provides a dynamic bridge between objectsimplemented using object models. Using the present invention, there isno need to define a static interface between objects and their objectmodels. Mediating component 204 brokers a message by determining theinterface requirements as each request arises during run-time. Thus,there is no need to generate and create a static messaging interface todefine the communication between a client object and a server object.There is no need to write, compile and link IDLs each time that a newobject class is added to an application. Mediating component 204 locatesthe server object to process the client's message. Mediating component204 identifies the expected method specification and arguments for theserver. Mediating component 204 translates the client's message usinginformation obtained about the server object.

The message is sent by mediating component 204 to the server object.Mediating component 204 uses a distributed object model or protocol toforward the message to the server object. The distributed object modelis preferably NeXT's DO. However, other distributed object models (e.g.,CORBA or Microsoft's Network OLE or Distributed COM) can be used.

Thus, for example, when a connection request is received in System A,mediating component 204 determines whether a server object in System Bcan service the message. For example, mediating component 204 queriesinformation available in object model B to determine whether a serverobject exists in that system and created in that model that can processthe message using the arguments supplied by the client object. If aserver object exists, mediating component 204 determines the methodspecification and the number and type of arguments expected by theserver object. If necessary, mediating component 204 returns a proxyobject to the requester. When a message is directed to the server objectvia the proxy object, mediating component 204 performs a mapping, ortranslation, of arguments for use by the server object. Mediatingcomponent 204 then immediately translates the message such that it canbe understood by the server object, and forwards the translatedinformation to the server object. In this way, the mediating component204 carries out dynamic translation at run-time.

Mediating component 204 provides a set of mappings between objects andobject models. When a reference is made by a client object for a serverobject, mediating component 204 manages a reference by a client objectto a server object. In addition, if the server is a part of a network,mediating component 204 locates the server object by querying each ofthe plurality of servers running on the network. A reference to theserver object is managed by mediating component 204. Thus, mediatingcomponent 204 provides a mapping between objects implemented using likeor different object models. For example, mediating component 204 createsa proxy object and a stub object. The proxy object maintains a referenceto the client object. The stub object maintains the reference to theserver object. Mediating component 204 maps an association between aproxy object and the stub object. If the server object is found, theserver object's calling format is returned to mediating component 204.Mediating component 204 uses the calling format information to translatethe client object's message for use by the server object.

Mediating component 204 can reside on either the client or the serverand can run in a process (i.e., a discrete address space) or in asingle-process machine. Preferably, mediating component 204 resides on acomputer that is running a windowing environment such as MicrosoftWindows. That is, mediating component 204 can function with anyoperating environment having the ability to send and receive messages.Further, the functionality of mediating component 204 described withreference to objects can be implemented in an environment other than anobject-oriented environment.

Object messages can be sent in either direction between client andserver. Thus, for example, an object message that originates in anobject implemented using object model B in System B (System 206) istransmitted to and processed by a server object implemented using objectmodel A in System A (System 202). A response can be sent between theserver object in System A and the client object in System B (System206). Similarly, a client object implemented using object model A inSystem A (System 202) generates a message that is sent to a serverobject implemented using object model B in System B (System 206). Aresponse that is generated by the server object in System B istransmitted to the client object in System A.

FIGS. 3A-3C provide configurations for exemplary embodiments of thepresent invention. Referring to FIG. 3A, mediating component 204 resideson server machine 304. Server machine 304 is running, for example, aVisual C++ application program under Microsoft Windows and using OLE/COMas Object Model B. A client machine 302 is running, for example, anObjective-C application program using Object Model A in NeXT's NEXTSTEP3.3 environment or OPENSTEP 4.0 for Windows NT using NeXT's D′OLE™Distributed OLE software, Distributed Object (DO), or PortableDistributed Objects (PDO) object models. Client object 306 isimplemented using Object Model A on client machine 302. Client object306 transmits a message directed to server object 308. Server object 308is implemented using Object Model B on server machine 304. Machines 302and 304 may also be processes rather than physical machines.

The message generated by client object 306 is directed to server object308 on server machine 304 (i.e., a remote object with respect to clientobject 306). A mechanism is used by client machine 302 to forward themessage to the remote object's machine (e.g., server 304). Theforwarding mechanism is, for example, that used in NeXT Software Inc.'sDO system or the technology disclosed in U.S. Pat. No. 5,481,721entitled Method for Providing Automatic and Dynamic Translation ofObject Oriented Programming Language-Based Message Passing intoOperation System Message Passing Using Proxy Objects and assigned toNeXT Software, Inc. In NeXT's DO, a proxy object 310 is used torepresent the remote object (e.g., server object 308). By using proxyobject 310, client object 306 does not need to obtain the actuallocation of server object 308. Client object 306 sends a messagedirected to server object 308 via proxy object 310 and connection 348.Proxy object 310 forwards the message to proxy object 314 on server 304via transport layer 318. That is, proxy object sends the message totransport layer 318 via connection 346. Transport layer 318 sends themessage to proxy object 314 via connection 344. Transport layer 318 usesa mechanism for transporting the message to a remote machine such as,for example, Transmission Control Protocol/Internet Protocol (TCP/IP).Remote Procedure Calls, such as the RPC facilities of MS Windows NT, isanother example of a mechanism that can be used to forward a message toa remote machine.

ORB 312 runs on server machine 304. ORB 312 acts as a control modulethat receives a message initiated by a client and creates a dynamicmapping between the client and a server to enable transmission ofmessages. During execution, ORB 312 is capable of creating a dynamicmessaging interface between two objects or processes using separateobject models.

When it is invoked, ORB 312 vends itself on the network. That is, ORB312 registers on the network using a name or identifier. Other objectson the network can locate ORB 312 using its registered name. Clientobject 306 connects to ORB 312 via its well known (or registered) name.FIGS. 8A-8B provide an example of a process flow for establishing aconnection and generating a mapping between a client and server objectaccording to an embodiment of the invention.

At step 802, client object 306 connects to ORB 312 via its well knownname. Client object 306 requests a connection to server object 308 atstep 804.

At step 806 (i.e., “server object exists?”), ORB 312 determines whetherserver object 308 is available on server machine 304. To identify aserver object, for example, ORB 312 communicates with an interfacerepository or object database for each object model that resides onserver machine 304 to locate server object 308. (Under MS OLE/COM, theobject database is termed a COM server and is implemented as a .DLL or.EXE file.) If server object 308 does not exist, ORB 312 can notifyclient object 306 at step 808, and processing ends for the currentrequest at step 826.

If ORB 312 determines (at step 806) that server object 308 does exist,processing continues at step 810 to examine mapping information forserver object 308. ORB 312 stores mapping information from previousconnections. The mapping information can be stored in one or moretables, for example. The mapping information includes an associationbetween a proxy object and its related server object and the serverobject's stub object. For example, a mapping table entry for serverobject 308 contains a pointer to server object 308, stub object 316 andproxy object 314. At step 810, ORB 312 examines the mapping informationto determine whether a mapping entry exists for server object 308.

At step 812 (i.e., “mapping exists?”), if a mapping entry exists forserver object 308, processing continues at step 814 to retrieve thepointer to the proxy object associated with server object 308 (e.g.,proxy object 314 in FIG. 3A). If it is determined (at step 812) thatthere is no mapping information for server object 308, processingcontinues at step 816 to create a proxy object for server object 308(e.g., proxy object 314).

At step 818 (i.e., “stub object exists?”), ORB 312 makes a determinationwhether stub object 316 exists for server object 308. If it does notexist, processing continues at step 820 to create stub object 316 andprocessing continues at step 822. If it does exist, processing continuesat step 822. At step 822, ORB 312 creates an entry in the mapping tablethat identifies server object 308, proxy object 314, and server object316. At step 824, ORB 312 returns proxy object 314 to client object 306.Processing ends for the connection request at step 826.

Thus, when a connection request is received from client object 306, ORB312 establishes a connection between client object 306 and server object308. The connection between client object 306 and server object 308 isformed via proxy object 314 and stub object 316. Client object 306 canthen send a message to server object 308 using the connection. When arequest (e.g., a message from client object 306 to execute a method ofan object created under the Microsoft Excel application program runningin OLE/COM on server machine 304) is transmitted to server machine 304,ORB 312 intercepts the message. The connection established betweenclient object 306 and server object 308 by ORB 312 is used to transmitthe message to server object 308. A response generated by server object308 is sent to client object 306 via the same connection.

As illustrated in FIG. 3A, the connection can be indirect and consist ofmultiple components and connections. Client object 306 is connected toproxy object 310 via connection 348. Connection 346 forms a connectionbetween proxy object 310 and transport layer 318. The message is sent bytransport layer 318 to server machine 304 and received by proxy object314 via connection 344. Proxy object sends the message to server stub316 via 342. Stub object 316 sends the message to server object 308 viaconnection 340.

Proxy object 314 and stub object 316 handle the message received fromclient object 306. For example, proxy object 314 receives a DO messagesent by client object 306 via proxy object 310 and transport layer 318.Proxy object 314 forwards the message to stub object 316. Stub object316 translates the message and its arguments so that the arguments canbe understood by server object 308 (e.g., an object created withMicrosoft's Excel running in the OLE/COM object model). For example,stub object 316 translates the message's operation into an operationidentifier that is expected by server object 308. In addition, one orall of the message's arguments can be translated for server object 308.For example, if the server object is expecting an object as one of itsarguments, stub object 316 can translate an argument contained in themessage sent by client object 306 into this expected object.

Stub object 316 forwards the message to server object 308. Server object308 processes the message (e.g., it executes a requested message) andreturns a response to stub object 316. Stub object 316 performs argumenttranslation for the response. The response is received by stub object316 and forwarded to proxy object 314. Proxy object 314 translates theresponse using the protocol of object model A (the protocol of clientobject 306) and packages the response for transmittal across transportlayer 318. The response is transmitted to proxy object 310 via transportlayer 318. Proxy object 310 forwards the response to client object 306.

In FIG. 3A, mediating component 204 resides on the server machine.Alternatively, mediating component 204 can reside on the client machine.FIG. 3B provides a configuration example wherein mediating component 204is resident on the client machine. The client machine 322 is using theOLE/COM object model under Microsoft Windows, for example.

As described above, ORB 312 of mediating component 204 vends itself onthe network. When a request is made, ORB 312 creates the proxy and/orstub object, if they don't already exist. In addition, ORB 312 monitorsand intercepts messages. A connection can be established between clientobject 308 and server object 306 using the process flow exemplified inFIGS. 8A-8B, for example. When client object 308 transmits a request toserver object 306, ORB 312 intercepts the message.

As in FIG. 3A, the connection between the client and server objects usesone or more connections and components. Client object 308 is connectionto server object 306 via proxy object 314, stub object 316, transportlayer 318 and proxy object 310 using connections 352, 342, 350, 346, and348.

In some instances, a client object may query whether a server object canrespond to a request before the client object actually sends therequest. In this case, mediating component 204 responds in theaffirmative. That is, if client object 308 sends a query messageinitially, mediating component 204 responds by indicating that it isable to respond to the request. In so doing, mediating component 204 caneliminate the need to send the initial message across to the server andwait for a response. It is only necessary to transmit the request to theserver. When client object 308 receives the affirmative response, itpackages its request and arguments into a message using the protocolspecified for object model B. Client object 308 sends the message toproxy object 314.

When the message is received, the proxy object 314 translates themessage using the protocol specified by object model A. Proxy object 314forwards the message to stub object 316. For example, proxy object 314attempts to invoke the message and is also unable to perform therequested operation. As a result, proxy object 314 faults and forwardsthe message to stub object 316. Stub object 316 translates thearguments, if necessary, to correspond to the type of arguments expectedby server object 306. Stub object 316 is unable to service the request.Stub object 316 packages the message for transmittal over transportlayer 318 to proxy object 310 on server machine 324.

Upon receipt, proxy object 310 discards the transport layer packaging,and forwards the message to server object 306. Server object 306services the request and returns its response using the messagingprotocol of Object Model A. Server object 306 sends the message to proxyobject 310. Proxy object 310 packages the response for transmittalacross transport layer 318 to client machine 322. The response isreceived from transport layer 318 by stub object 316. Stub object 316strips the transport layer packaging off the response. Using the mappingretained by ORB 312, the response is returned from stub object 316 toproxy object 314. Proxy object 314 translates the response using themessaging protocol of Object Model B. The return value is returned byproxy object 314 to client object 308.

The previous configuration examples in FIGS. 3A and 3B use an mediatingcomponent 204 on either the client or server machine. It is alsopossible for mediating component 204 to reside on both the client andserver machines. FIG. 3C provides a configuration example wherein boththe client and server machines include an mediating component.

The connection between the client object 308C and server object 306S isformed indirectly using multiple connections and components. Clientobject 308C connected to proxy object 314C via connection 370. Proxyobject 314C is connected to stub object 316C via connection 368. Stubobject 316C is connected to transport layer 318 via connection 366.Transport layer is connected via connection 364 to proxy object 314S.Proxy object 314S is connected to stub object 316S via connection 362.Stub object 316S is connected via connection 360 to server object 306S.

Referring to FIG. 3C, client machine 332 and server machine 334 are bothusing Object Model B. However, Object Model B on client machine 332 doesnot have the ability to forward a message to Object Model B on servermachine 334, and vice versa. That is, Object Model B does not havedistributed object capability; it can not forward messages betweenobjects that reside on different machines.

Using the configuration illustrated in FIG. 3C, for example, the presentinvention can be used to act as a bridge between instances of the sameobject model that reside on different machines. Thus, a non-distributed,non-networked object model can become a distributed, networked objectmodel using the present invention.

Referring to FIG. 3C, client and server machines 332 and 334 are runningMicrosoft's Windows NT operating system which uses non-distributedOLE/COM, for example. The communication protocol used between mediatingcomponents 204C and 204S is a distributed object model such as NeXT'sDO, for example. Client object 308C is executing on client machine 332.Server object 306S is executing on server machine 334. ORB 312C createsand manages proxy object 314C and stub object 316C. Similarly, ORB 312Screates and manages proxy object 314S and stub object 316S.

Client object 308C can forward a request to server object 306S viamediating components 204C and 204S. Client object 308C sends an initialquery to determine whether its request can be processed. ORB 312Cintercepts the message. ORB 312C responds to the query by stating thatit can service the request. When the affirmative response is received byclient object 308C, it packages its request and any arguments usingObject Model B's messaging format.

Client object 308C sends the message which is intercepted by ORB 312Cand processed by proxy object 314C. Since the message is intended for aserver object in a like object model (i.e., server object 306S runningin Object Model B), there is no need for proxy object 314C to translatethe message into the server object's object model. However, it may benecessary to translate the arguments to accommodate the argumentexpectations of server object 306S as described above. Argumenttranslation can be performed by mediating component 204C or 204S.

Proxy object 314C forwards the message to stub object 316C. Stub object316C packages the message for transmittal to server machine 334 viatransport layer 318. The message is intercepted by ORB 204S on servermachine 334. Proxy object 314S strips off the transport layer packagingand forwards the message to stub object 316S. Stub object 316S forwardsthe message to server object 306S.

Server object 306S processes the message and forwards a response to stubobject 316S. The message is forwarded to client object 308C via proxyobject 314S, transport layer 318, stub object 316C and proxy object314C. Argument translation can be performed on either client machine 332by mediating component 204C or on the server machine 334 by mediatingcomponent 204S.

Thus, as described above, the mediating component of the presentinvention acts as a bridge between objects implemented using like ordifferent object models. An mediating component can act as a bridgebetween two objects implemented using two instances of the same objectmodel running on different machines. The invention enables thedistribution of objects such as OLE Automation objects. An mediatingcomponent can reside on either the server machine, the client machine,or both.

Server-Side Bridge

The bridging capabilities of the present invention can be implemented onthe server machine. In one example, the server machine is running MSExcel software under the MS Windows operating system. The server machineis using the non-distributed OLE/COM object model. The bridgingcapabilities can be implemented as an executable file (.EXE) or dynamiclink library (.DLL) in the Windows environment, for example. A clientobject executing on a client machine generates a request for processingby the MS Excel instance running on the server machine. The clientmachine is running NEXTSTEP or OPENSTEP using NeXT's DO object modelwith D'OLE or PDO. FIGS. 4A-4C provide a process flow for brokeringobject messages between NeXT's object model on a client machine and theOLE/COM on a server machine.

Referring to FIGS. 4A-4C, the client establishes a connection with theclient proxy on the client machine at step 402. The connection can occuras a consequence of some user action, or on startup, for example. Atstep 404, the client sends a message directed to a remote server.

At step 406, the client proxy intercepts the message. Because the clientproxy is unable to respond to the message, it enters a fault state. As aresult of the fault state, the client proxy packages the message andforwards it via a transport layer to the server proxy object at step408. At step 410, the server proxy object receives the message andstrips off the transport layer packaging.

At step 412, the server proxy object sends the message to the stubobject. The server stub attempts to perform the operation specified inthe message and enters a fault state at step 414. At step 416, theserver stub object queries the server object model for method andargument information of a server object.

At step 418 (i.e., “can server object respond to message?”), the serverstub object determines whether the server object to which the message isdirected is capable of responding to the message. For example, theserver stub object invokes a GetIDsofNames routine to determine whetherthe specified method is a valid method of the server object. TheGetIDsOfNames method converts text names of properties and methods intoa corresponding set of dispIDs that uniquely identify a method andarguments. If the method or arguments are invalid (e.g., there is nodispID for a specified method or argument), the server stub objectraises an error response at step 420 and processing continues at step428 to forward the response to the client object.

If it is determined that the server object can respond (i.e., the testof step 418 is affirmative), processing continues at step 422 totranslate the arguments for the receiving object model (i.e., the serverobject's object model). For example, an OLE/COM data structure iscreated and the arguments are stored in the data structure. In addition,the server stub object can convert an argument from its original type toone expected by the server object. For example, if the server objectexpects an object as an argument but the client specified a non-objectvalue, the server stub converts the argument to an object. Similarly, anumeric argument can be converted to a string, for example.

At step 424, the client object's message is invoked on the serverobject. For example, to invoke a method using an object in the OLE/COMobject model, the Invoke method is called on the COM server objectspecifying the DispID as an argument. The arguments are retrieved fromthe OLE/COM data structure. The method is identified by specifying themethod's identifier (DispID).

At step 426, the server stub waits for a response generated from themethod invoked in the server object. At step 428, the server stubtranslates the response. The response can be a response received fromthe method processing, or from an error condition raised duringprocessing, for example. The response is packaged and transmitted acrossthe transport layer to the proxy object on the client machine at step430. At step 432, the message is unpackaged by the client proxy objectand returned to the client object. Processing ends at step 434.

Client-Side Bridge

The bridging capabilities of the present invention can be implemented onthe client machine. In one example, the client machine is running MSWord in the Windows environment. The client machine is using the OLE/COMobject model. An object created (instantiated) by MS Word generates amessage request to print a document on a PostScript printer on a servermachine. The server machine is running NEXTSTEP or OPENSTEP using NeXT'sDO object model with D'OLE or PDO. FIGS. 5A-5C provide a process flowfor brokering object messages between the OLE/COM object model on aclient machine and NeXT's object model on a server machine.

At step 502, the ORB creates the proxy object on the client machine. TheORB can create the proxy object as a result of a request from a clientobject, for example. At step 504, the client object queries the proxyobject to determine whether it can process the client object's request.As previously described, the OLE Automation mechanism uses a two messageapproach. A first message from the client object queries the serverobject for a dispID. That is, the client object sends a GetIDsOfNames toidentify the dispID of the method. In the prior art, the server objectresponds by either sending a dispID (if the method identified by thesender is valid), or by sending an error (if an invalid method isspecified by the client object). If a dispID is returned, the clientobject sends a second message to server object using the dispID of themethod.

In addition to the messaging load on the network, this approach requiresthat the communication between a client and server be permitted onlyafter a method is identified. Thus, if the client object wishes toinvoke another method on the server object, it must use the two messageapproach to identify a new dispID. Further, if a new method is added bythe server object, a new proxy and stub implementation must beestablished between the client and server objects.

In contrast, the invention uses a technique that allows a client objectto send a message of which the server object has no knowledge. Theserver object can add new methods without any change being made on theclient side. When the client object sends a GetIDsOfNames message toobtain the dispID for a method of the server object, the inventiondynamically creates a unique ID for the requested method, if one doesn'talready exist. The invention uses this ID to respond to the clientobject's first message. The response includes the unique ID. In sodoing, the invention indicates that a server object is able to performthe desired method (i.e., the invention responds affirmatively to theclient object's first message). This unique ID is retained along withthe name of the requested method. The unique ID is used to invoke toquery the server for the requested method when the client object sends asecond, invocation message.

Thus, when the proxy object receives the message sent by the clientobject in step 506, it returns an affirmative response that indicatesthat the client object's request can be processed. The response includesthe unique ID to identify the method which the ORB retains to identifythe message when the client invokes it. The client object creates amessage (e.g., operation specification and arguments) that includes thetag using the OLE/COM message protocol at step 508. At step 510, theproxy object translates the client object's message for use on theserver machine's object model (e.g., NeXT DO).

At step 512, the message is invoked on the proxy object previously setup by the ORB. The proxy object is unable to perform the specifiedoperation and faults at step 514. At step 516, the proxy object forwardsthe message to the stub object. The stub object attempts to perform themessage's operation and faults at step 518. At step 520, the stub objectpackages the message and forwards the message via the transport layer tothe server machine.

The proxy object receives the message and strips off the transportlayer's message packaging at step 522. The server proxy object forwardsthe message to the server object at step 524. The server proxy objectwaits for a response from the server object at step 526. At step 528,the response sent by the server object is translated for transmittal viathe transport layer by the server's proxy object. The message istransmitted via the transport layer to the client's stub object at step530. At step 532, the stub object strips off the transport layerpackaging and forwards the message to the client machine's proxy object.At step 534, the proxy object translates the message using the clientobject's object model and returns the response to the client object.Processing ends at step 536.

Client and Server Bridge

The bridging capabilities of the present invention can be implemented onboth the client and server machines. Using the present invention, anon-networked object model (e.g., OLE/COM) can communicate acrossmachines. In one example, both the server and client machines arerunning the MS Windows environment and using the OLE/COM object model. Aclient object created (instantiated) by MS Excel on the client machinegenerates a request message for processing by an object instantiated bythe MS Word application program running on the server machine. Using thepresent invention, the Excel object can send a message to the MS Wordobject on another machine. FIGS. 6A-6C provide a process flow forbrokering object messages between OLE Automation objects running ondifferent machines.

At step 602, ORBs on the server and client machines are created. Clientand server proxies are established by the ORBs. The ORBs monitor formessages and intercept messages from a client object to a server object.Steps 604 and 606 correspond to steps 504 and 506 of FIG. 5A. At step604, the client object queries the proxy object (e.g., GetIDsOfNames) todetermine whether it can process the client object's request. The proxyobject responds in the affirmative and includes a unique ID for themethod at step 606. In so doing, the invention provides a mechanism thatallows a client object to send a message to a server object that theserver object is previously unaware. The server object can add newmethods without any change being made to the client object. As far asthe client object is concerned, the unique ID sent by the proxy objectis the dispID of the actual method in the server object.

The client object creates a message (e.g., operation specification andarguments) including the tag and using the OLE/COM message protocol atstep 608. At step 610, the proxy object translates the client object'smessage. There is no need to translate the message from one object modelprotocol to another since both client and server objects are using thesame object model. However, the proxy object can translate argumentsinto the types that are expected by the server object, if that isrequired.

At step 612, the message is invoked on the proxy object. The proxyobject is unable to perform the specified operation and faults at step614. At step 616, the proxy object forwards the message to the stubobject. The stub object attempts to perform the message's operation andfaults at step 618. At step 620, the stub object packages the messageand forwards the message via the transport layer to the server machine.

The message is received by the proxy object on the server machine andstrips off the transport layer's message packaging at step 622. Theserver proxy object forwards the message to the stub object which inturn forwards the message to the server object at step 624. The serverproxy object waits for a response from the server object at step 626. Atstep 628, the stub object forwards the response to the proxy object. Theproxy object packages the response and forwards it to the client machinevia the transport layer at step 630. At step 632, the stub object stripsoff the transport layer packaging and returns the response to the clientmachine's proxy object. At step 634, the proxy object translates theresponse (e.g., returns a value translation) and returns the response tothe client object. Processing ends at step 636.

Argument Translation

The invention allows an object to communicate with another objectregardless of the object models used to implement the objects. A messagesent by an object implemented using one object model can containarguments that are used by another object that is implemented using asecond object model. Each argument has a type (e.g., numeric, string,and object). The argument types used by the sending object may beincompatible with those used by the receiving object. The inventionprovides a mechanism to translate these incompatible argument types.

In the NEXTSTEP or OPENSTEP environment, arguments can be passed as avalue or an object, for example. Examples of the types associated with avalue are short, long, integer, and float. An argument can be an objectsuch as the NSString object type, or class. NSString that includesstring functionality is one example of an object class supported byNEXTSTEP and OPENSTEP. An argument can be an object that is an instanceof any of the object classes supported by NEXTSTEP and OPENSTEP.

In a Windows environment, an argument can be a value of type short,long, integer, float and double, for example. In addition, the OLE/COMobject model supports types such as OLE String and OLE Automation. AnOLE String type is used for arguments of type string.

OLE Automation is a subset of OLE/COM that is used to dynamically invokemethods that manipulate the contents of scriptable objects. OLEAutomation provides classes of objects that include automation servers,automation controllers, collection, application, document, documents,and font referred to herein as OLE Automation objects.

As indicated in the discussion above, there are some argument types thatcan be passed between two environments without translation. However,some argument types are unique to, or incompatible with, the argumenttypes of another environment. Therefore, a translation mechanism isneeded to allow arguments to pass between the environments.

The translation mechanism of the invention is implemented in themediating component. Referring to FIGS. 3A-3C, for example, thetranslation mechanism is implemented in mediating component 204, 204C,and 204S. The translation can be performed in either the proxy or stubobjects. If delayed stack creation is used, argument translation isoptimally performed by the last intervening object (e.g., stub object316 for server object 308 or stub object 316 for server object 306).

The translation mechanism processes each argument in a message and aresponse. The type that is given by the sending object and the typeexpected by the receiving object are compared. If the types areincompatible, a translation is performed to convert the sending type tothe receiving type. The following functionality can be used to translatearguments having unique, or incompatible, types between theNEXTSTEP/OPENSTEP and Windows (or OLE) environments. It should beapparent that the translation mechanism can be adapted for use betweenany two environments. An example of program code that implementsargument translation between the NEXTSTEP/OPENSTEP and OLE environmentsis provided in the section entitled “Translation Code Examples”.

NEXTSTEP/OPENSTEP to OLE

The NEXTSTEP/OPENSTEP environment includes object classes such asNSString that are incompatible with a Windows object class. Numericargument types can be passed without translation. Therefore, atranslation is needed for certain argument types used in theNEXTSTEP/OPENSTEP before the arguments can be passed to the Windowsenvironment. FIG. 7A provides an example of a process flow fortranslating argument types from the NEXTSTEP/OPENSTEP environment to theWindows environment according to an embodiment of the invention. Theprocess flow of FIG. 7A is performed for each argument in a clientobject's message or any return values contained in a server object'sresponse.

At step 702 (“argument is in the form of an object?), a determination ismade whether the argument is an object. If it is not an object, thevalue is passed to the object running in the NEXTSTEP/OPENSTEPenvironment as a value. That is, there is no need to translate theargument, and the translation processing for that argument ends at step712.

If it is determined that the argument is in the form of an object (anaffirmative determination is made at step 702), processing continues atstep 706 to identify the object's type, or class. At step 706 (“NSStringobject?”), a determination is made whether the object is an NSStringobject. If it is determined that the object is of class NSString,processing continues at step 708 to convert the argument to an OLEstring type argument, and processing ends for the current argument atstep 712. If it is determined that the argument is not an NSStringobject (at step 706), processing continues at step 710 to generate aproxy object for the object. The proxy object can be used to transmitmessage to and from the object argument, for example. The currentargument's translation processing ends at step 712.

OLE to NEXTSTEP/OPENSTEP

The Windows environment includes object classes such as the OLEAutomation object classes that are unique to that environment.Therefore, a translation mechanism is needed before these arguments canbe passed to the NEXTSTEP/OPENSTEP environment from the Windowsenvironment. FIG. 7B provides an example of a process flow fortranslating argument types from the Windows environment to theNEXTSTEP/OPENSTEP environment according to an embodiment of theinvention. The process flow of FIG. 78 is performed for each argument ina client object's message or any return values contained in a serverobject's response.

At step 732 (“argument is an OLE string?”), a determination is madewhether the current argument is an OLE string. If so, processingcontinues at step 734 to convert the argument to an NSString object. Forexample, an instance of the NSString object class is instantiated andthe string value is stored in a property of the NSString objectinstance. Processing then ends for the current argument at step 746.

If it is determined (at step 732) that the argument is not an OLEstring, processing continues at step 736. At step 736 (“NULL value?”), adetermination is made whether the value of the argument is set to NULL.If it is, processing continues at step 738 to set the value of theargument to zero and processing ends for the current argument at step746. If not, processing continues at step 740 (“OLE Automation object?”)to determine whether the argument is in the form of an OLE Automationobject. If the argument is an OLE Automation object, processingcontinues at step 742 to create a proxy for the OLE Automation object.The proxy can be used to communicate with the OLE Automation object.Translation processing for the current argument ends at step 746.

If it is determined at step 740 that the argument is not an OLEAutomation object, processing continues at step 744 to process a numericargument value. At step 744, an NSNumber object is created and thenumeric value is stored in a property of the object. Translationprocessing ends for the current argument at step 746.

Delayed Stack Creation

When an object processes a message, it retrieves the method andarguments from the message and pushes the arguments on a stack. This isreferred to as unraveling the message. The object then invokes themethod. In an environment where the message is sent from a client objectto a server object via one or more intervening objects, it isunnecessary for each intervening object to unravel the message when themethod is intended for another object and the intervening object isincapable of performing the requested operation. When the interveningobject is unable to perform the requested operation after unraveling themessage, it repackages the method and arguments and sends the message tothe next object. This is unnecessary and inefficient. Thus, theinvention optimizes processing of a message by an intervening object bydelaying the method and argument retrieval and stack creation until hemessage is received by an object that is capable of performing therequested operation.

The invention optimizes the message transmission by eliminating the needto unravel the message at each intervening point. Referring to FIG. 3A,for example, it is unnecessary for both proxy object 314 and stub object316 to unravel the message sent from client machine 302.

The invention waits until the message is received by the lastintervening object (e.g., the server object's stub object) before themessage is unraveled. Thus, for example, the message is not unraveleduntil it is received by stub object 316 in FIG. 3A. When proxy object314 receives the message from client object 306, it passes the messageto stub object 316. Proxy object 314 does not unravel the message.

FIG. 9 provides an example of a delayed stack creation process flowaccording to an embodiment of the invention. At step 902, an object(e.g., proxy object 314) receives a message. At step 904 (i.e., “lastintervening object?”), the object determines whether it is the lastintervening object (e.g., stub object 316). If not, the object transmitsthe message to the next object at step 914 and processing for thecurrent object ends at step 918. That is, if the object is not the lastintervening object, it acts as a conduit for the message. It sends themessage to the next object without unraveling the message. It does notbuild an argument stack or attempt to perform the operation specified bythe message, for example.

If, at step 904, the object determines that it is the last interveningobject, processing continues at step 906. The message is unraveled atstep 906. The object retrieves the method and arguments from themessage. At step 908, interface information is retrieved for the serverobject (e.g., server object 308). The interface information can beretrieved from an interface repository such as a COM server in MSOLE/COM, for example.

At step 910 (i.e., “argument translation needed?”), the objectdetermines whether any argument translation is needed. If so, processingcontinues at step 912 to translate an argument. Processing thencontinues at step 910 to process any remaining arguments. If it isdetermined at step 910 that no argument translation is needed (or iscompleted), processing continues at step 916 to forward the message tothe server object. At step 918, processing ends for the current message.

As illustrated in FIG. 9, an intervening object acts as a conduitsending the message to the next intervening object without unravelingthe message. The last intervening object unravels the message andperforms any necessary argument translation. Unnecessary messageprocessing is therefore avoided and message transmission is optimized.

Translation Code Examples

The following provides code examples that translate arguments betweenthe OLE (or Windows) and NEXTSTEP/OPENSTEP environments.

Thus, a method and apparatus for dynamically brokering object messagesamong object models has been described.

1. A method of dynamically communicating an object message between aclient and a server comprising the steps of: intercepting a messagegenerated by said client in a first object model; examining a secondobject model for interface information for said server; using theinterface information to generate a translated message for said server;and forwarding said translated message to said server.
 2. The method ofclaim 1 further comprising the step of transmitting a response from saidserver to said client.
 3. The method of claim 1 further comprising thesteps of: said client sending a query to determine if said server isable to respond to said message; and responding affirmatively to saidquery regardless of whether said server is able to respond to saidmessage.
 4. The method of claim 1 wherein said step of mapping furthercomprises the steps of: creating a proxy object; creating a stub object;and creating an association between said proxy object and said stubobject.
 5. The method of claim 4 further comprising the step of creatingan association between said client and said proxy object.
 6. The methodof claim 4 further comprising the step of creating an associationbetween said server and said stub object.
 7. The method of claim 4further comprising the step of creating an association between saidserver and said proxy object.
 8. The method of claim 4 furthercomprising the step of creating an association between said client andsaid stub object.
 9. The method of claim 1 wherein said message includesan operation and a plurality of arguments, said step of generatingfurther comprises the steps of: translating said operation for saidserver, translating said plurality of arguments for said server; andgenerating a translated message using a message protocol of said server.10. The method of claim 9 wherein said step of translating saidarguments further comprises the steps of: determining the expectednumber and type of arguments of said server; determining whether anexpected argument type is different than an argument type; andtranslating one of said plurality of arguments to an expected argumenttype when its type is different than said expected argument type. 11.The method of claim 2 wherein said step of transmitting furthercomprises the steps of: determining the expected type of said response;determining whether said type of said response is different than saidexpected type; translating said response from said type to said expectedtype when said type is different than said expected type; generating atranslated response using a message protocol of said client; andtransmitting, using said mapping, said translated response to saidclient.
 12. An article of manufacture comprising: a non-transitorycomputer usable medium having computer readable program code embodiedtherein for dynamically handling an object message between a client anda server, the computer readable program code in said article ofmanufacture comprising: computer readable program code configured tocause a computer to intercept a message generated by said client in afirst object model; computer readable program code configured to cause acomputer to examine a second object model for interface information forsaid server; computer readable program code configured to cause acomputer to use the interface information to generate a translatedmessage for said server; and computer readable program code configuredto cause a computer to forward said translated message to said server.13. The article of manufacture of claim 12 further comprising: computerreadable program code configured to cause a computer to send a query todetermine if said server is able to respond to said message; andcomputer readable program code configured to cause a computer to respondaffirmatively to said query regardless of whether said server is able torespond to said message.
 14. The article of manufacture of claim 12wherein said program code configured to cause a computer to generate amap of said client to said sever further comprises: computer readableprogram code configured to cause a computer to create a proxy object;computer readable program code configured to cause a computer to createa stub object; and computer readable program code configured to cause acomputer to create an association between said proxy object and saidstub object.
 15. The article of manufacture of claim 14 furthercomprising computer readable program code configured to cause a computerto create an association between said client and said proxy object. 16.The article of manufacture of claim 14 further comprising computerreadable program code configured to cause a computer to create anassociation between said server and said stub object.
 17. The article ofmanufacture of claim 14 further comprising computer readable programcode configured to cause a computer to create in association betweensaid server and said proxy object.
 18. The article of manufacture ofclaim 14 further comprising computer readable program code configured tocause a computer to create an association between said client and saidstub object.
 19. The article of manufacture of claim 12 wherein saidmessage includes an operation and a plurality of arguments, said programcode configured to cause a computer to generate a translated messagefurther comprises: computer readable program code configured to cause acomputer to translate said operation for said server; computer readableprogram code configured to cause a computer to translate said pluralityof arguments for said server; and computer readable program codeconfigured to cause a computer to generate a translated message using amessage protocol of said server.
 20. The article of manufacture of claim19 wherein said program code configured to cause a computer to translatesaid arguments further comprises: computer readable program codeconfigured to cause a computer to determine the expected number and typeof arguments of said server; a computer readable program code configuredto cause a computer to determine whether an expected argument type isdifferent than an argument type; and computer readable program codeconfigured to cause a computer to translate one of said plurality ofarguments to an expected argument type when its type is different thansaid expected argument type.
 21. The article of manufacture of claim 12wherein said program code configured to cause a computer to transmitsaid response further comprises the steps of: computer readable programcode configured to cause a computer to determine the expected type ofsaid response; computer readable program code configured to cause acomputer to determine whether said type of said response is differentthan said expected type; computer readable program code configured tocause a computer to translate said response from said type to saidexpected type when said type is different than said expected type;computer readable program code configured to cause a computer togenerate a translated response using a message protocol of said client;and computer readable program code configured to cause a computer totransmit, using said mapping, said translated response to said client.22. (canceled)
 23. (canceled)
 24. (canceled)
 25. (canceled) 26.(canceled)
 27. (canceled)
 28. (canceled)
 29. (canceled)
 30. (canceled)31. (canceled)
 32. A computer system, comprising: a communicationinterface; and a processor coupled to the communication interface andconfigured to: intercept a message generated in a first object model;examine a second object model for interface information of a server; usethe interface information to generate a translated message for saidserver; and forward said translated message to said server via thecommunication interface.